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Abstract 


A software defined radio {SDR) architecture used in space-based platforms proposes 
to standardize certain aspects of radio development such as interface definitions, 
functional control and execution, and application software and firmware 
development, NASA has charted a team to develop an open software defined 
radio hardware and software architecture to support NASA missions and 
determine the viability of an Agency-wide Standard. A draft concept of the 
proposed standard has been released and discussed among organizations in the 
SDR community. Appropriate leveraging of the JTRS SCA, OMG’s SWRadio 
Architecture and other aspects are considered. 

A standard radio architecture offers potential value by employing common waveform 
software instantiation, operation, testing and software maintenance, While 
software defined radios offer greater flexibility, they also poses challenges to the 
radio development for the space environment in terms of size, mass and power 
consumption and available technology. An SDR architecture for space must 
recognize and address the constraints of space flight hardware, and systems along 
with flight heritage and culture, 

NASA is actively participating in the development of technology and standards related 
to software defined radios. As NASA considers a standard radio architecture for 
space communications, input and coordination from government agencies, the 
industry, academia, and standards bodies is key to a successful architecture. The 
unique aspects of space require thorough investigation of relevant terrestrial 
technologies properly adapted to space. The talk will describe NASA's current 
effort to investigate SDR applications to space missions and a brief overview of a 
candidate architecture under consideration for space based olafforms. 

FYI Only: not part of actual presentation > 




Overview 


• Communications Technology at Glenn Research Center 

• NASA’s Mission Drivers and Applications 

• NASA’s SDR Reference Architecture 

• Relationship among standard bodies - NASA, OMG, SDRF, 
IEEE, JTRS 

• Concluding Remarks 




Aerospace Communications 
Historical Perspective 


• From the early 1970’s to 1 998 GRC’s Space Comm 
program’s primary responsibility was to open new 
frequency bands and provide enabling 
communications technology to the commercial 
SATCOM industry. 

- Provided the high power communications payload to the 
joint-Canadian CTS Satellite that opened the Ku-band for 
DBS and FSS services in the late 1970’s. 

* Received an Emmy from the National Academy of 
Television Arts and Sciences 

- Developed and validated high-risk Ka-band technology via 
ACTS Satellite Program for the next generation satellite 
systems, 1990’s 

* ACTS inducted into Space Technology Hall of Fame 

• Pioneered satellite communications to aircraft 

• Developed technologies to enhance Internet over 
satellite operation 



Aerospace Communications 
Today 


• Develop next generation space communication 
systems and networking technologies for NASA 
Missions and to enhance NASA’s Space 
Communications Infrastructure. 

- Software Radio/Digital Communications 

- Antennas (high gain deployable, steerable/directional arrays) 

- Power Amplifiers 

- System Architectures, Networking, and Analysis 

• Develop communication and networking systems 
technologies to enhance the National Airspace 
System. 







Aerospace Communications 
Research & Technology 
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Mission Drivers and Requirements for SDR 
Recent Reconfigurable SDR Missions 
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Future Space Communications Architecture 
A Network of Networks 


Crewed Vehicles 

• Transport Vehicles 

• Space Stations/Outposts 

• Crew Activity (i,e, EVA) 


Other 

- Launch Vehicles 

• Sub-Orbital Vehicles 

• Ground Stations 


Mission Types 


Robotic Spacecraft 

* Science Satellites 

* Orbiting Relay Satellites 


Surface Radios 

• Rovers 

• Science Elements 

• EVA 


Drivers for NASA Space SDR 


* Mission Services 

* On-orbit Operations 


- Space Network, Ground 

- Reliability (hw/sw, single point 


Network, Deep Space Network, 

failures) 


* User Platforms 

- Contingencies 


- International Space Station, 

- Interoperability 


Shuttle, Earth Science, Space 
Science, Space Exploration, 

(among /between NASA and 
GGA assets) 


Crew Exploration Vehicle - 

- New opportunities/updates 


Orion 

* Space Environment 


* Mission Operations 

- Space Effects (eg HW - 


- Telemetry, command, control, 

SEU/TID, SW-EDAC) 


science, tracking, scheduling, 

- Capa bi 1 rty - te c h nology lag 


ranging (inter-satellite), 

compared to terrestrial 


networking 

equivalents 


* Waveform Aspects 

* Future Missions Requirements 


- Frequency, data rate, access, 

- Development time 


modulation, networking 

- Changes (req u i re me nts cree p ) 

- Insert technology 
advancements 



- Culture 

to 



Timeline of SDR Benefits 
Before and After Launch 
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Common s / w reuse s/w reuse New Shared Waveform Waveform Waveform 

platform/ across reduces dual functional resc >urces upgrade to change to change for 
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Typical Development Typical operations Cyde 

and Test Cycle 

Potential to add years to the useful life of 
deployed hardware by reducing mission risk 


11 



Open Architecture SDR 
Sample Benefits/Limitations 


Benefits 

* Flexible 

- Hardware and software standard 
interfaces enable interoperability 

- Open interface and hardware/software 
separation allows technology insertion for 
planned obsolescence 

- Re-programmability allows pre- and post- 
launch changes 

- Enables backwards compatibility with 
legacy systems 

* Cost 

* Simplify new mission adoption by reuse 
of standard hw and sw components 

- Multiple applications on a single 
hardware system 

- Resources 

- Reduced radio count by combining 
functions to single/fewer processors or 
platforms 


Limitations 

* Reliability 

- Space qualification and lack of direct control 
over third party developed software 

- Difficult to verify and validate software 
compared to traditional hardware process 

- Need to verify on-orbit software 
reconfigurations 


• Cost 

- Potentially high cost to create and sustain 
architecture if substantially different from SC A 
or commercial standard 

- Is common NASA, DoD, and commercial 
architecture needed to maximize market for 
space radios to reduce cost 


* Resources 

- Potential for increased processing (i.e. power) 
requirements and larger form factors vs 
predominately hardware based solutions (e g , 
ASIC) 

- Additional processes to prevent memory 
corruption, resource contention, space effect 
upsets, and lockup conditions 
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NASA Reconfigurable, Software Defined Radio 
Technology in Flight 




Blackjack 


Champ 




Open Architecture for Space, 
Why now? 


/ = 

Signal Processing 
Advancements 

Software/Firmware 

Emerging Open Architectures 

New Radio Technology 



Technology advancements in signal 
processing hardware make it 
possible for space based 
reconfigurable platforms 


Technology allows use of more 
software intensive systems for 
communication and navigation 
functions. 

Standard architectures for SDR 
emerging 


Commonality/ 
Technology Insertion 

Adaptable Operations, Fault 
Recovery, Flexibility 


> JTRS, OMG, SDR Forum, 
etc... 


> SDR’s being used in missions and 
technology demos (e g. MRO, STS- 
107) without benefit of commonality 
or leverage from one development 
to another 
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Applying SDR and Standard Architectures to NASA 



/ vendor’s \ 
' proprietary 
architecture 


NASA 

Mission Classes 
and Applications 


Reconfigurable 

Platforms 


Open 

Architectures 


Isolate SW from HW to 
promotes reuse 
Promotes/enables multi- 
vendor participation 
Expandability - provide 
or define more interfaces 
and capability as 
requirements and 
technology mature. 


Missions will 
apply 

reconfigurable 

radio 

technology and 
standard 
architectures to 
best meet 
requirements 


Less dependence on specific 
vendor's implementation will ' 
reduce NASA cost to develop ) | 
augment, and maintain 
reconfigurable systems. 

Provides path to standard test 
qualification procedures and 
validation/verification procedures 
as software use increases 


Vendors will 
pursue 

reconfigurable 
platforms 
going forward 


conventional 
radios will be 
reconfigurable 
{e g. SDR) 
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Aspects of SDR and Architectures 
How the pieces fit... 



“SDR” means more than just 
“reconfigurable" 


Today's radio technology offers new 
development and operational 
paradigms 

- Upgradable 

- Flexible 

- Industry trends to SW based systems 


Architecture adds framework to 
reconfigurable (SDR) transceiver 
technology 

- M u Iti-ve nd or pa rtici pation 

- Common Interfaces 

- Tech nology I nse rtio n 

- Common Specification 
* Reuse 

- Software verification - Developing a 
qualification approach suitable for 
missions 


Today’s Emerging Radios 
Common, Open Architecture 




Space Communications Organization Chart 
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SDR Architecture Work 


SAT Approach to Development and Implementation 
of the STRS SDR Standard Architecture 


Create a broad-based SDR development and verification 
infrastructure to enable a future Agency-wide SDR standard 

1 . Develop the STRS SDR Standard Architecture Specification 

* Maintain flexibility as appropriate, solicit feedback from 

government and industry / 

* Release 1.0 released in May 2900©— 

2. Develop an SDR distributed HW and SW component library 

* Solicit component entries from all viable sources 

* Projects select and procure library components as needed 

3. Develop Design Reference Implementations using standard- 
compliant library components 

4. Develop tools and testbeds for SDR design and validation 

5. Demonstrate STRS-compliant units in space 















SAT Key Recommendations to SCAWG 


• Recognize that SDRs will play a key role in future NASA missions 

- SDR technology demonstrated in flight testing and operations 

* Blackjack, LPT, Electra 

- Today’s space radios typically have significant functionality implemented in 
software 

- Standardized SDRs may provide cost savings overtime and multiple projects 

* However, business case needs to be compelling 

* Commonality should reduce development risk and IMRE costs 

• Adopt the STRS Standard as a reference HW and 3W SDR Standard 
and the associated Design Reference Implementations as such 

- Promote a broad environment of acceptance and evolution of the Standard 

• Phase in compliance to the STRS Standard over time 

- Encourage, but do not require, compliance to early versions of the Standard 

- The STRS Standard will be flexible and will be allowed to evolve as appropriate 

• Support technologies required to improve SDR performance for space 

- radiation mitigation, processor throughput, FPGAs, ADC rates, memory, etc. 





NASA’s SDR Reference Architecture for Space 
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STRS SDR System Context 
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STRS Layered Software Model 


Waveform Applications 

- Isolate from hardware 

- Uses POSIX APIs to access RTOS 

- Uses STRS APIs to access STRS infrastructure 

- promote waveform portabiiity/taYenng 

High Level Services 

- Control waveform 

- Monitor waveform (QoS) 

STRS Infrastructure 

- System management 

- Device control 

- Data transfer 

- Optimized for platform 

RTOS 

Real-Time Operating System (COTS) 

- System implementing a subset of POSIX 

- Network Support 

BSP (Board Support Package) 

- Hardware Abstraction Layer (HAL) 

- Drivers 

- Hardware interface (HID) 

Hardware 

Hardware communications equipment 
(e g. FPGA, DSP, A to D, and D to A) 

- HW Interface Definition - Facilitate HW tech 
insertion from multiple vendors (e g. ICD) 


Waveform Applications and High Level Services 

1 

POSIX API Subset 

STRS API 

HI 


STRS infrastructure 

1 * 

OS : Network Stack 

; 1 


HAL API 

BSP Drivers 

GPM 

Specialized HW 
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STRS Software Abstraction 
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STRS Software Rule Set Sample 


* The API layer shall consist of published STRS APIs and a defined 
subset of industry standard POSIX APIs 

* The STRS infrastructure shall implement the STRS APIs and 
system management, device control, data transfer functions 

* All STRS waveform applications shall use the STRS API suite to 
instantiate and control the waveform functionality 

• The STRS API provides the interfaces that allow applications to be 
instantiated and use platform services - these APIs also enable 
communication between waveform and application components 

* Operating environment consists of STRS infrastructure, real time 
OS, board support packages, hardware abstraction layers 

* STRS configuration files shall contain platform and waveform 
specific information to allow customization of installed waveforms. 

- The configuration file contains the parametric values for configurable 
components as welt as filenames for loadable devices (FPGA, DSP, 
etc.) 



rf Module 
‘Clock Interface 
‘Frequency Conversion 
*RF components 
(switches, diplexer, filters, 
LNAs and power 
amplifiers} 


Signal Processing 
Module 

‘Data Interface (e g. 
high rate, direct 10} 
•High speed DSP 
•Data conversion 
(packetize) 
•Components 
include ASIC's, 
FPGA'S, DSP s, 
memory, and 
connection 
fabric/bus (e g, flex- 
fabric) 




‘Spacecraft telemetry interface 
•Test interface 

•Components: GPP, memory (e,g. 
SRAM, SDRAM) 

Control & configure the radio. 




Waveform Component Allocation to 
Hardware Modules 



Waveforms are comprised of software 
components with signal processing 
algorithms necessary to transmit and 
messages 


•Waveform 
components 
allocated to 
processing (GPP) 
and specialized 
hardware (SPM). 




STRS Hardware Module & Interface Descriptions 



♦Hardware Interface 
Definition {e g. address, 
dock, physical) 


•Module Interfaces abstract the 
module functionality for data flow to 
waveform components Enables 
multiple vendors to provide different 
modules or add modules to existing 
radios. 

Electrical interfaces, connector 
requirements, and physical 
requirements are specified by the 
platform provider. 


•High level services 
used to control and 
monitor waveform 
♦Configuration files 
describe the 
hardware 

environment for the 
STRS architecture. 


rpcse Processor 


Lx™ Spree 
5HMI 


HohSpeet 


Module 


•APIs separate waveform from operating 
environment - enabling waveform 
portability. 

*OE implements the system management, 
device control, data transfer functions 


STSR Interface Descriptions 


Hardware 

♦ Module definitions provided to organize common functions 

♦ Module interfaces abstracts the module functionality for data flow to waveform 
components 

- Enable multiple vendors to provide different modules or add modules to existing radios. 

- Provide common test interface/procedures 

♦ Ha rd wa re I nte rf a ce Defin itio n 

- The electrical interfaces, connector requirements, and physical requirements are specified by the 
platform provider. 

- HID shall be published for each module so 3rd party developers have the structure under which 
they can develop new modules 

Software 

♦ Layers help define interfaces between components 

♦ Certain layers separate SW from SW and other SW from HW (Le. abstract) 

♦ APIs defined by the architecture separate waveform from operating environment for 
waveform portability and software reuse 

♦ The STRS Infrastructure will use the HAL information to initialize the hardware drivers 
such that the control and data messages will be appropriately delivered to the module 

- Method/function used , calling sequence, return values, an explanation of its functionality, any 
preconditions before using the method/function, and the status after using the methodtfu notion 

- Hardware address and data interfaces, interrupt input and output, power connections, control and 
data lines necessary to operate in the STRS platform environment (firmware code portability) 

- Portable operating environment 





SDR Standards Coordination 


* Organizations pursuing SDR Standards 

- Software Communications Architecture (SCA JPEO/JTRS) 

•Specialized Hardware Processors Extension to the SC A (SHPEJPQ) 

- PIM/PSM For Software Radio Components (P2SRC:OMG) 

- PI 900 (IEEE EMC Society) 

- Space Telecommunications Radio System (3TRS:NASA) 

- Others ... 

* NASA participates in many of the SDR Standard activities in various ways 

* NASA's STRS developed in 2004/2005 considered aspects of SCA and early 
versions of SWRADIO, 

* NASA will strive to leverage commercial standards as they meet the 
requirements of space missions 

* Continue to monitor SCA, OMG, and PI 900 advancements 

- NASA investigating the application of current SWRADIO PtM/PSM for Software 
Radio Components in conjunction with SDR Forum, Space Applications Study Group 




Government and Standard Bodies 
Coordination for Space SDR 



SDR & SIRS Architecture Conclusions 


• Reconfigurable SDR will enable new mission concepts 

- Remote/autonomous operations 

- Future cognitive radios 

• STRS Architecture provides commonality among reconfigurable SDR 
developed by NASA 

- Provides a coordinated method across the agency to apply SDR 
technology 

- Program/mission risk reduction 

- A J lows techno logy i nf u s ion 

- Reduces vendor dependence 

• STRS Architecture will evolve before becoming a required Standard 

* Waveform Control 

- Navigation, Security, Networking.,, 

- Business case for Standard Architecture pending,,. 

- Leverage best aspects of DoD's JTRS SCA and industry practice 

• Exploration Vision will present opportunities to apply SDR 
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